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Abstract 


The functions of the Public Switched Telephone Network (PSTN) are 
rapidly migrating to the Internet. This is generating new 
requirements for many traditional elements of the PSTN, including 
Telephone Numbers (TNs). TNs no longer serve simply as telephone 
routing addresses: they are now identifiers that may be used by 
Internet-based services for a variety of purposes including session 
establishment, identity verification, and service enablement. This 
problem statement examines how the existing tools for allocating and 
managing telephone numbers do not align with the use cases of the 
Internet environment and proposes a framework for Internet-based 
services relying on TNs. 
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Problem Statement 


The challenges of utilizing Telephone Numbers (TNs) on the Internet 
have been known for some time. Internet telephony provided the first 
use case for routing telephone numbers on the Internet in a manner 
similar to how calls are routed in the Public Switched Telephone 
Network (PSTN). As the Internet had no service for discovering the 
endpoints associated with telephone numbers, ENUM [RFC6116] created a 
DNS-based mechanism for translating TNs into URIs, as used by 
protocols such as SIP [RFC3261]. The resulting database was designed 
to function in a manner similar to the systems that route calls in 
the PSTN. Originally, it was envisioned that ENUM would be deployed 
as a global hierarchical service; however, in practice, it has only 
been deployed piecemeal by various parties. Most notably, ENUM is 
used as an internal network function and is rarely used between 
service provider networks. The original ENUM concept of a single 
root, el64.arpa, proved to be politically and practically 
challenging, and less centralized models have thus flourished. 
Subsequently, the Data for Reachability of Inter-/Intra-NetworKk SIP 
(DRINKS) framework [RFC6461] showed ways that service providers might 
provision information about TNs at an ENUM service or similar 
Internet-based directory. These technologies have also generally 
tried to preserve the features and architecture familiar to the PSTN 
numbering environment. 


Over time, Internet telephony has encompassed functions that differ 
substantially from traditional PSTN routing and management, 
especially as non-traditional providers have begun to utilize 
numbering resources. An increasing number of enterprises, over-the- 
top Voice over IP (VoIP) providers, text messaging services, and 
related non-carrier services have become heavy users of telephone 
numbers. An enterprise, for example, can deploy an IP Private Branch 
Exchange (PBX) that receives a block of telephone numbers from a 
carrier and then, in turn, distributes those numbers to new IP 
telephones when they associate with the PBX. Internet services offer 
users portals where they can allocate new telephone numbers on the 
fly, assign multiple "alias" telephone numbers to a single line 
service, implement various mobility or find-me-follow-me 
applications, and so on. Peer-to-peer telephone networks have 
encouraged experiments with distributed databases for telephone 
number routing and even allocation. 


This dynamic control over telephone numbers has few precedents in the 
traditional PSTN outside of number portability. Number portability 
allows the capability of a user to choose and change their service 
provider while retaining their TN; it has been implemented in many 
countries either for all telephony services or for subsets (e.g., 
mobile). However, TN administration processes rooted in PSTN 
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technology and policies made number porting fraught with problems and 
delays. Originally, processes were built to associate a specific TN 
to a specific service provider and never change it. With number 
portability, the industry had to build new infrastructure and new 
administrative functions and processes to change the association of 
the TN from one service provider to another. Thanks to the 
increasing sophistication of consumer mobile devices as Internet 
endpoints as well as telephones, users now associate TNs with many 
Internet applications other than telephony. This has generated new 
interest in models similar to those in place for administering 
freephone (non-geographic, toll-free numbers) services in the United 
States, where a user purchases a number through a sort of number 
registrar and controls its administration (such as routing) on their 
own, typically using Internet services to directly make changes to 
the service associated with telephone numbers. 


Most TNs today are assigned to specific geographies, at both an 
international level and within national numbering plans. Numbering 
practices today are tightly coupled with the manner that service 
providers interconnect as well as with how TNs are routed and 
administered: the PSTN was carefully designed to delegate switching 
intelligence geographically. In interexchange carrier routing in 
North America, for example, calls to a particular TN are often handed 
off to the terminating service provider close to the geography where 
that TN is assigned. But the overwhelming success of mobile 
telephones has increasingly eroded the connection between numbers and 
regions. Furthermore, the topology of IP networks is not anchored to 
geography in the same way that the telephone network is. In an 
Internet environment, establishing a network architecture for routing 
TNs could depend little on geography, relying instead on network 
topologies or other architectural features. Adapting TNs to the 
Internet requires more security, richer datasets, and more complex 
query and response capabilities than previous efforts have provided. 


This document attempts to create a common understanding of the 
problem statement related to allocating, managing, and resolving TNs 
in an IP environment, which is the focus of the IETF Managing, 
Ordering, Distributing, Exposing, and Registering telephone Numbers 
(MODERN) Working Group. It outlines a framework and lists motivating 
use cases for creating IP-based mechanisms for TNs. It is important 
to acknowledge at the outset that there are various evolving 
international and national policies and processes related to TNs, and 
any solutions need to be flexible enough to account for variations in 
policy and requirements. 
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26 


Definitions 


This section provides definitions for actors, data types, and data 
management architectures as they are discussed in this document. 
Different numbering spaces may instantiate these roles and concepts 
differently: practices that apply to non-geographic freephone 
numbers, for example, may not apply to geographic numbers, and 
practices that exist under one Numbering Authority may not be 
permitted under another. The purpose of this framework is to 
identify the characteristics of protocol tools that will satisfy the 
diverse requirements for telephone number acquisition, management, 
and retrieval on the Internet. 


sl. Actors 


The following roles of actors are defined in this document. 


Numbering Authority: A regulatory body within a region that manages 
that region’s TNs. The Numbering Authority decides national 
numbering policy for the nation, region, or other domain for which 
it has authority, including what TNs can be allocated, which are 
reserved, and which entities may obtain TNs. 


Registry: An entity that administers the allocation of TNs based on 
a Numbering Authority’s policies. Numbering Authorities can act 
as the Registries themselves, or they can outsource the function 
to other entities. Traditional registries are single entities 
with sole authority and responsibility for specific numbering 
resources, though distributed registries (see Section 2.3) are 
also in the scope of this framework. 


Credential Authority: An entity that distributes credentials, such 
as certificates that attest the authority of assignees (defined 
below) and delegates. This document assumes that one or more 
Credential Authorities may be trusted by actors in any given 
regulatory environment; policies for establishing such trust 
anchors are outside the scope of this document. 


Registrar: An entity that distributes the telephone numbers 
administered by a Registry; typically, there are many Registrars 
that can distribute numbers from a single Registry, though 
Registrars may serve multiple Registries as well. A Registrar has 
business relationships with number assignees and collects 
administrative information from them. 


Communication Service Provider (CSP): A provider of communication 
service where those services can be identified by TNs. This 
includes both traditional telephone carriers or enterprises as 
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well as service providers with no presence on the PSTN who use 
TNs. This framework does not assume that any single CSP provides 
all the communication service related to a particular TN. 


Service Enabler: An entity that works with CSPs to enable 
communication service to a User: perhaps a vendor, a service 
bureau, or a third-party integrator. 


User: An individual reachable through a communication service: 
usually a customer of a Communication Service Provider. 


Government Entity: An entity that, due to legal powers deriving from 
national policy, has privileged access to information about number 
administration under certain conditions. 


Note that an individual, organization, or other entity may act in one 
or more of the roles above; for example, a company may be a CSP and 
also a Registrar. Although Numbering Authorities are listed as 
actors, they are unlikely to actually participate in the protocol 
flows themselves; however, in some situations, a Numbering Authority 
and Registry may be the same administrative entity. 


All actors that are recipients of numbering resources, be they a CSP, 
Service Enabler, or User, can also be said to have a relationship to 
a Registry of either an assignee or delegate. 


Assignee: An actor that is assigned a IN directly by a Registrar; an 
assignee always has a direct relationship with a Registrar. 


Delegate: An actor that is delegated a TN from an assignee or 
another delegate who does not necessarily have a direct 
relationship with a Registrar. Delegates may delegate one or more 
of their IN assignment(s) to one or more subdelegates from further 
downstream. 


As an example, consider a case where a Numbering Authority also acts 
as a Registry, and it issues blocks of 10,000 TNs to CSPs that, in 
this case, also act as Registrars. CSP/Registrars would then be 
responsible for distributing numbering resources to Users and other 
CSPs. In this case, an enterprise deploying IP PBXs also acts as a 
CSP, and it acquires number blocks for its enterprise seats in chunks 
of 100 from a CSP acting as a Registrar with whom the enterprise has 
a business relationship. The enterprise is, in this case, the 
assignee, as it receives numbering resources directly froma 
Registrar. As it doles out individual numbers to its Users, the 
enterprise delegates its own numbering resources to those Users and 
their communication endpoints. The overall ecosystem might look as 
follows. 


Peterson & McGarry Informational [Page 6] 


RFC 8396 


|Numbering | 
|Authority|Registry 
+----+----+ 


v 10,000 TNs 


+--------- + 
| cSP  |Registrar 
+----+----+ 
| 
V 100 TNs 
e n + 
| PBX  |Assignee 
a E + 
| 
V 1 TN 
E ri + 
| User |Delegate 
+--------- + 
Figure 1: 
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Chain of Number Assignment 


The following data types are defined in this document. 


Administrative Data: 
relevant actors; 
etc.), contact data for the assignee 
does not require real-time access as 


Assignment data related to the 
it includes TN status 


TN and the 
unassigned, 

and typically 
not required for 


(assigned, 
or delegate, 
this data is 


ordinary call or session establishment. 


Service Data: Data necessary to enable 
includes addressing data and service 
necessary to complete calls, it must 


Administrative and service data can fit 


Public: Anyone can access public data. 
list of which numbering resources 


(unallocated number ranges) 


service for the TN; it 
features. Since this data is 
be obtained in real time. 


into three access categories: 


Such data might include a 
are 


available for acquisition from the Registry. 


Semi-restricted: 
data. For example, 
data in some closed environment. 
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Only a subset of actors can access semi-restricted 
CSPs may be able to access other CSP’s service 
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Restricted: Only a small subset of actors can access restricted 
data. For example, a Government Entity may be able access contact 
information for a User. 


While it might appear there are really only two categories, public 
and restricted (based on the requestor), the distinction between 
semi-restricted and restricted is helpful for the use cases below. 


2.3. Data Management Architectures 


This framework generally assumes that administrative and service data 
is maintained by CSPs, Registrars, and Registries. The terms 
"registrar" and "registry" are familiar from DNS operations, and 
indeed the DNS provides an obvious inspiration for the relationships 
between those entities described here. Protocols for transferring 
names between registries and registrars have been standardized in the 
DNS space for some time (see [RFC3375]). Similarly, the division 
between service data acquired by resolving names with the DNS 
protocol versus administrative data about names acquired through 
WHOIS [RFC3912] is directly analogous to the distinction between 
service and administrative data described in Section 2.2. The major 
difference between the data management architecture of the DNS and 
this framework is that the distinction between the CSP and User, due 
to historical policies of the telephone network, will often not 
exactly correspond to the distinction between a name service anda 
registrant in the DNS world -- a User in the telephone network is 
today at least rarely in a direct relationship with a Registrar 
comparable to that of a DNS registrant. 


The role of a Registry described here is a "thin" one, where the 
Registry manages basic allocation information for the numbering 
space, such as information about whether or not the number is 
assigned, and if assigned, by which Registrar. It is the Registrar 
that, in turn, manages detailed administrative data about those 
assignments, such as contact or billing information for the assignee. 
In some models, CSPs and Registrars will be combined (the same 
administrative entity), and in others the Registry and Registrar may 
similarly be composed. Typically, service data resides largely at 
the CSP itself, though in some models a "thicker" Registry may itself 
contain a pointer to the servicing CSP for a number or number block. 
In addition to traditional centralized Registries, this framework 
also supports environments where the same data is being managed by 
multiple administrative entities and stored in many locations. A 
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distributed registry system is discussed further in [DRIP]. To 
support those use cases, it is important to distinguish the 
following: 


Data Store: A data store is a service that stores and enables access 
to administrative and/or service data. 


Reference Address: A reference address is a URL that dereferences to 
the location of the data store. 


Distributed Data Stores: In a distributed data store, administrative 
or service data can be stored with multiple actors. For example, 
CSPs could provision their service data to multiple other CSPs. 


Distributed Registries: Multiple Registries can manage the same 
numbering resource. In these architectures, actors could interact 
with one or multiple Registries. The Registries would update each 
other when change occurs. The Registries have to ensure that data 
remains consistent, e.g., that the same TN is not assigned to two 
different actors. 


3. Framework 


The framework outlined in this document requires three Internet-based 
mechanisms for managing and resolving TNs in an IP environment. 

These mechanisms will likely reuse existing protocols for sharing 
structured data; it is unlikely that new protocol development work 
will be required, though new information models specific to the data 
itself will be a major focus of framework development. Likely 
candidates for reuse here include work done in DRINKS [RFC6461] and 
Web Extensible Internet Registration Data Service (WEIRDS) [RFC7482], 
as well as the Telephone-Related Information (TeRI) framework 
[TERI-INFO]. 


These protocol mechanisms are scoped in a way that makes them likely 
to apply to a broad range of future policies for number 
administration. It is not the purpose of this framework to dictate 
number policy but instead to provide tools that will work with 
policies as they evolve going forward. These mechanisms, therefore, 
do not assume that number administration is centralized nor that 
number allocations are restricted to any category of service 
providers, though these tools must and will work in environments with 
those properties. 
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The three mechanisms are: 


Acquisition: A protocol mechanism for acquiring TNs, including an 
enrollment process. 


Management: A protocol mechanism for associating data with TNs. 
Retrieval: A protocol mechanism for retrieving data about TNs. 


The acquisition mechanism will enable actors to acquire TNs for use 
with a communication service by requesting numbering resources from a 
service operated by a Registrar, CSP, or similar actor. TNs may be 
requested either on a number-by-number basis or as inventory blocks. 
Any actor who grants numbering resources will retain metadata about 
the assignment, including the responsible organization or individual 
to whom numbers have been assigned. 


The management mechanism will let actors provision data associated 
with TNs. For example, if a User has been assigned a TN, they may 
select a CSP to provide a particular service associated with the TN, 
or a CSP may assign a TN to a User upon service activation. In 
either case, a mechanism is needed to provision data associated with 
the TN at that CSP and to extend those data sets as CSPs (and even 
Users) require. 


The retrieval mechanism will enable actors to learn information about 
TNs. For real-time service data, this typically involves sending a 
request to a CSP; for other information, an actor may need to send a 
request to a Registry rather than a CSP. Different parties may be 
authorized to receive different information about TNs. 


As an example, a CSP might use the acquisition interface to acquire a 
chunk of numbers from a Registrar. Users might then provision 
administrative data associated with those numbers at the CSP through 
the management interface and query for service data relating to those 
numbers through the retrieval interface of the CSP. 
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|Registry| 
+---+----+ 
V 
+--------- + 
|Registrar | 
+--------- + 
\ 
\\ 
Acquisition \\ 
\\4+-----=- + 
\ CSP | 
+---+---+ 
A A 
Management | | Retrieval 
+------- ++ +4+------- + 
| User | | User | 
+-------- + +-------- + 
(Delegate) (Caller) 
Figure 2: Example of the Three Interfaces 
4. Use Cases 


The high-level use cases in this section will provide an overview of 
the expected operation of the three interfaces in the MODERN problem 


space. 


4.1. Acquisition 

There are various scenarios 
relevant actors, that is, a 
are three actors from which 
CSP, and a User (presumably 


for how TNs can be acquired by the 

CSP, Service Enabler, and a User. There 
numbers can be acquired: a Registrar, a 
one who is delegating to another party). 


It is assumed either that Registrars are the same entity as 
Registries or that Registrars have established business relationships 


with Registries that enable 
Registries administer. 
either from a CSP, 
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a Registry, 
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them to distribute the numbers that the 
a User may acquire TNs 
or an intermediate delegate. 
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4.1.1. Acquiring TNs from Registrar 


The most traditional number acquisition use case is one where a CSP, 
such as a carrier, requests a block of numbers from a Registrar to 
hold as inventory or assign to customers. 


Through some out-of-band business process, a CSP develops a 
relationship with a Registrar. The Registrar maintains a profile of 
the CSP and assesses whether or not CSPs meet the policy restrictions 
for acquiring TNs. The CSP may then request TNs from within a 
specific pool of numbers in the authority of the Registry, such as 
region, mobile, wireline, or freephone. The Registrar must 
authenticate and authorize the CSP and then either grant or deny a 
request. When an assignment occurs, the Registry creates and stores 
administrative information related to the assignment, such as TN 
status and Registrar contact information, and removes the specific 
TN(s) from the pool of those that are available for assignment. As a 
part of the acquisition and assignment process, the Registry provides 
to the Registrar any tokens or other material needed by a Credential 
Authority to issue credentials (for example, Secure Telephone 
Identity Revisited (STIR) certificates [RFC8226]) used to attest the 


assignment for future transactions. Depending on the policies of the 
Numbering Authorities, Registrars may be required to log these 
operations. 


Before it is eligible to receive TN assignments, per the policy of a 
Numbering Authority, the CSP may need to have submitted (again, 
through some out-of-band process) additional qualifying information 
such as the current utilization rate or a demand forecast. 


There are two scenarios under which a CSP requests resources: either 
they are requesting inventory or they are requesting for a specific 
User or delegate. For the purpose of status information, TNs 
assigned to a User are always considered assigned, not inventory. 
The CSP will associate service information for that TN (e.g., a 
service address) and make it available to other CSPs to enable 
interconnection. The CSP may need to update the Registrar regarding 
this service activation; this is part of the "TN status" maintained 
by the Registrar. 


There are also use cases in which a User can acquire a TN directly 
from a Registrar. Today, a User wishing to acquire a freephone 
number may browse the existing inventory through one or more 


Registrars, comparing their prices and services. Each such Registrar 
either is a CSP or has a business relationship with one or more CSPs 
to provide services for that freephone number. In this case, the 


User must establish some business relationship directly with a 
Registrar, similar to how such functions are conducted today when 
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Users purchase domain names. In this use case, after receiving a 
number assignment from the Registrar, a User will obtain 
communication service from a CSP and provide to the CSP the TN to be 
used for that service. The CSP will associate service information 
for that TN (e.g., the service address) and make it available to 
other CSPs to enable interconnection. The User will also need to 
inform the Registrar about this relationship. 


4.1.2. Acquiring TNs from CSPs 


Today, a User typically acquires a TN from a CSP when signing up for 
a communication service or turning on a new device. In this use 
case, the User becomes the delegate of the CSP. A reseller ora 
service bureau might also acquire a block of numbers from a CSP to be 
issued to Users. 


Consider a case where a User creates or has a relationship with the 
CSP and subscribes to a communication service that includes the use 
of a TN. The CSP collects and stores administrative data about the 
User. The CSP then activates the User on their network and creates 
any necessary service data to enable connectivity with other CSPs. 
The CSP could also update public or privileged databases accessible 
by other actors. The CSP provides any tokens or other material 
needed by a Credential Authority to issue credentials to the User 
(for example, a STIR certificate [RFC8226]) to prove the assignment 


for future transactions. Such credentials could be delegated from 
the one provided by the Credential Authority to the CSP to continue 
the chain of assignment. CSPs may be required to log such 


transactions if required by the policy of the Numbering Authority. 


Virtually, the same flow would work for a reseller: it would form a 
business relationship with the CSP, at which point the CSP would 
collect and store administrative data about the reseller and give the 
reseller any material needed for the reseller to acquire credentials 
for the numbers. A User might then, in turn, acquire numbers from 
the reseller: in this case, the delegate redelegating the TNs would 
be performing functions done by the CSP (e.g., providing any 
credentials or collecting administrative data or creative service 
data). 


The CSP could assign a TN from its existing inventory or it could 
acquire a new TN from the Registrar as part of the assignment 
process. If it assigns it from its existing inventory, it would 
remove the specific TN from the pool of those available for 
assignment. It may also update the Registrar about the assignment so 
the Registrar has current assignment data. If a reseller or delegate 
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CSP is acquiring the numbers, it may have the same obligations to 
provide utilization data to the Registry as the assignee, per 
Section 4.1.1. 


4.2. Management 


The management protocol mechanism is needed to associate 
administrative and service data with TNs and may be used to refresh 
or rollover associated credentials. 


4.2.1. Management of Administrative Data 


Administrative data is primarily related to the status of the TN, its 
administrative contacts, and the actors involved in providing service 
to the TN. Protocol interactions for administrative data will 
therefore predominantly occur between CSPs and Users to the Registrar 
or between Users and delegate CSPs to the CSP. 


Some administrative data may be private and would thus require 
special handling in a distributed data store model. Access to it 
does not require real-time performance; therefore, local caches are 
not necessary, and the data will include sensitive information such 
as User and contact data. 


Some of the data could lend itself to being publicly available, such 
as CSP and TN assignment status. In that case, it would be deemed 
public information for the purposes of the retrieval interface. 


4.2.1.1. Managing Data at a Registrar 


After a CSP acquires a TN or block of TNs from the Registrar (per 
Section 4.1.1), it then provides administrative data to the Registrar 
as a step in the acquisition process. The Registrar will 
authenticate the CSP and determine if the CSP is authorized to 
provision the administrative data for the TNs in question. The 
Registry will update the status of the TN, i.e., that it is 
unavailable for assignment. The Registrar will also maintain 
administrative data provided by the CSP. 


Changes to this administrative data will not be frequent. Examples 
of changes would be terminating service (see Section 4.2.3.2), 
changing the name or address of a User or organization, or changing a 
CSP or delegate. Changes should be authenticated by a credential to 
prove administrative responsibility for the TN. 
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In some cases, such as the freephone system in North America today, 
the User has a direct relationship with the Registrar. Naturally, 
these Users could provision administrative data associated with their 
TNs directly to the Registrar just as a freephone provider today 
maintains account and billing data. While delegates may not 
ordinarily have a direct relationship to a Registrar, some 
environments (as an optimization) might want to support a model where 
the delegate updates the Registrar directly on changes, as opposed to 
sending that data to the CSP or through the CSP to the Registrar. As 
stated already, the protocol should enable Users to acquire TNs 
directly from a Registrar, which may or may not also act as a CSP. 

In these cases, the updates would be similar to those described in 
Section 4.2.1.1. 


In a distributed Registry model, TN status (e.g., allocated, 
assigned, available, or unavailable) would need to be provided to 
other Registries in real time. Other administrative data could be 
sent to all Registries, or other Registries could get a reference 
address to the host Registry’s data store. 


4.2.1.2. Managing Data at a CSP 


After a User acquires a TN or block of TNs from a CSP, the User will 
provide administrative data to the CSP. The CSP commonly acts as a 
Registrar in this case by maintaining the administrative data and 
only notifying the Registry of the change in TN status. In this 
case, the Registry maintains a reference address (see Section 2.3) to 
the CSP/Registrar’s administrative data store so relevant actors have 
the ability to access the data. Alternatively, a CSP could send the 
administrative data to an external Registrar to store. If there is a 
delegate between the CSP and User, they will have to ensure there is 
a mechanism for the delegate to update the CSP as change occurs. 


4.2.2. Management of Service Data 


Service data is data required by an originating or intermediate CSP 
to enable communication service to a User; a SIP URI is an example of 
one service data element commonly used to route communication. CSPs 
typically create and manage service data, however, it is possible 
that delegates and Users could as well. For most use cases involving 
individual Users, it is anticipated that lower-level service 
information changes (such as an end-user device receiving a new IP 
address) would be communicated to CSPs via existing protocols. For 
example, the baseline SIP REGISTER [RFC3261] method, even for bulk 
operations [RFC6140], would likely be used rather than through any 
new interfaces defined by MODERN. 
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4.2.2.1. CSP to Other CSPs 


After a User enrolls for service with a CSP, in the case where the 
CSP was assigned the IN by a Registrar, the CSP will then create a 
service address such as a SIP URI and associate it with the TN. The 
CSP needs to update this data to enable service interoperability. 
There are multiple ways that this update can occur, though most 
commonly service data is exposed through the retrieval interface (see 
Section 4.3). For certain deployment architectures, like a 
distributed data store model, CSPs may need to provision data 
directly to other CSPs. 


If the CSP is assigning a IN from its own inventory, it may not need 
to perform service data updates as change occurs because the existing 
service data associated with inventory may be sufficient once the TN 
is put in service. They would, however, likely update the Registry 
on the change in status. 


4.2.2.2. User to CSP 


Users could also associate service data to their TNs at the CSP. An 
example would be a User acquiring a TN from the Registrar (as 
described in Section 4.1.1) and wanting to provide that TN to the CSP 
so the CSP can enable service. In this case, once the User provides 
the number to the CSP, the CSP would update the Registry or other 
actors as outlined in Section 4.2.2.1. 


4.2.3. Managing Change 


This section will address some special management use cases that were 
not covered above. 


4.2.3.1. Changing the CSP for an Existing Service 


Consider the case where a User who subscribes to a communication 
service (and who received their TN from that CSP) wishes to retain 
the same TN but move their service to a different CSP. 


In the simplest scenario, where there’s an authoritative combined 
Registry/Registrar that maintains service data, the User could 
provide their credential to the new CSP and let the CSP initiate the 


change in service. The new CSP could then provide the new service 
data with the User’s credential to the Registry/Registrar, which then 
makes the change. The old credential is revoked and a new one is 


provided. The new CSP or the Registrar would send a notification to 
the old CSP so they can disable service. The old CSP will undo any 
delegations to the User, including contacting the Credential 
Authority to revoke any cryptographic credentials (e.g., STIR 
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certificates [RFC8226]) previously granted to the User. Any service 
data maintained by the CSP must be removed, and, similarly, the CSP 
must delete any such information it provisioned in the Registry. 


In a model similar to common practice in environments today, the User 
could alternatively provide their credential to the old CSP, and the 
old CSP would initiate the change in service. Or, a User could go 
directly to a Registrar to initiate a port. This framework should 
support all of these potential flows. 


Note that in cases with a distributed Registry that maintained 
service data, the Registry would also have to update the other 
Registries of the change. 


4.2.3.2. Terminating a Service 


Consider a case where a User who subscribes to a communication 
service (and who received their TN from the CSP) wishes to terminate 
their service. At this time, the CSP will undo any delegations to 
the User, which may involve contacting the Credential Authority to 
revoke any cryptographic credentials (e.g., STIR certificates 
[RFC8226]) previously granted to the User. Any service data 
maintained by the CSP must be removed, and similarly, the CSP must 
delete any such information it provisioned in the Registrar. 
However, per the policy of the Numbering Authority, Registrars and 
CSPs may be required to preserve historical data that will be 
accessible to Government Entities or others through audits, even if 
it is no longer retrievable through service interfaces. 


The TN will change state from assigned to unassigned, and the CSP 
will update the Registry. Depending on policies, the TN could go 
back into the Registry, CSP, or delegate’s pool of available TNs and 
would likely enter an aging process. 


In an alternative use case, a User who received their own TN 
assignment directly from a Registrar terminates their service with a 
CSP. At this time, the User might terminate their assignment from 
the Registrar and return the TN to the Registry for reassignment. 
Alternatively, they could retain the TN and elect to assign it to 
some other service at a later time. 


4.3. Retrieval 


Retrieval of administrative or service data will be subject to access 
restrictions based on the category of the specific data: public, 
semi-restricted, or restricted. Both administrative and service data 
can have data elements that fall into each of these categories. It 
is expected that the majority of administrative data will fall into 
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the semi-restricted category: access to this information may require 
some form of authorization, though service data crucial to 
reachability will need to be accessible. In some environments, it’s 
possible that none of the service data necessary to initiate 
communication will be useful to an entity on the public Internet, or 
that all that service data will have dependencies on the origination 
point for calls. 


The retrieval protocol mechanism for semi-restricted and restricted 
data needs a way for the receiver of the request to identify the 
originator of the request and what is being requested. The receiver 
of the request will process that request based on this information. 


4.3.1. Retrieval of Public Data 


Either administrative or service data may be made publicly available 
by the authority that generates and provisions it. Under most 
circumstances, a CSP wants its communication service to be publicly 
reachable through TNs, so the retrieval interface supports public 
interfaces that permit clients to query for service data about a IN. 
Some service data may, however, require that the client be authorized 
to receive it, per the use case in Section 4.3.3. 


Public data can simply be posted on websites or made available 
through a publicly available API. Public data hosted by a CSP may 
have a reference address at the Registry. 


4.3.2. Retrieval of Semi-restricted Administrative Data 


Consider a case in which a CSP is having service problems completing 
calls to a specific TN, so it wants to contact the CSP serving that 
TN. The Registry authorizes the originating CSP to access this 
information. It initiates a query to the Registry, the Registry 
verifies the requestor and the requested data, and the Registry 
responds with the serving CSP and contact data. However, CSPs might 
not want to make those administrative contact points public data: 
they are willing to share them with other CSPs for troubleshooting 
purposes, but not to make them available to general communication. 


Alternatively, that information could be part of a distributed data 


store and not stored at a monolithic Registry. In that case, the CSP 
has the data in a local distributed data store, and it initiates the 
query to the local data store. The local data store responds with 


the CSP and contact data. No verification is necessary because it 
was done when the CSP was authorized to receive the data store. 
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4.3.3. Retrieval of Semi-restricted Service Data 


Consider a case where a User on a CSP’s network calls a TN. The CSP 
initiates a query for service data associated with the TN to complete 
the call and will receive special service data because the CSP 
operates in a closed environment where different CSPs receive 
different responses, and only participating CSPs can initiate 
communication. This service data would be flagged as semi- 
restricted. The query and response have real-time performance 
requirements in that environment. 


Semi-restricted service data also works in a distributed data store 
model where each CSP distributes its updated service data to all 
other CSPs. The originating CSP has the service data in its local 
data store and queries it. The local data store responds with the 
service data. The service data in the response can be a reference 
address to a data store maintained by the serving CSP or it can be 
the service address itself. In the case where the response gives a 
reference address, a subsequent query would go to the serving CSP, 
who would, in turn, authorize the requestor for the requested data 
and respond appropriately. In the case, where the original response 
contains the service address, the requestor would use that service 
address as the destination for the call. 


In some environments, aspects of the service data may reside at the 
Registry itself (for example, the assigned CSP for a TN); thus, the 
query may be sent to the Registry. The Registry verifies the 
requestor and the requested data and responds with the service data, 
such as a SIP URI containing the domain of the assigned CSP. 


4.3.4. Retrieval of Restricted Data 


A Government Entity wishes to access information about a particular 
User who subscribes to a communication service. The entity that 
operates the Registry on behalf of the Numbering Authority in this 
case has some predefined relationship with the Government Entity. 
When the CSP acquired TNs from the Numbering Authority, it was a 
condition of that assignment that the CSP provide access for 
Government Entities to telephone numbering data when certain 
conditions apply. The required data may reside either in the CSP or 
in the Registrar. 


For a case where the CSP delegates a number to the User, the CSP 
might provision the Registrar (or itself, if the CSP is composed with 
a Registrar) with information relevant to the User. At such a time 
as the Government Entity needs information about that User, the 
Government Entity may contact the Registrar or CSP to acquire the 
necessary data. The interfaces necessary for this will be the same 
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as those described in Section 4.3; the Government Entity will be 
authenticated and an authorization decision will be made by the 
Registrar or CSP under the policy dictates established by the 
Numbering Authority. 


5. IANA Considerations 
This document has no IANA actions. 
6. Privacy Considerations 


This framework defines two categories of information about telephone 
numbers: service data and administrative data. Service data 
describes how telephone numbers map to particular services and 
devices that provide real-time communication for users. As such, 
service data could potentially leak resource locations and even 
lower-layer network addresses associated with these services, and in 
rare cases, with end-user devices. Administrative data more broadly 
characterizes who the administrative entities are behind telephone 
numbers, which will often identify CSPs but some layers of the 
architecture could include Personally Identifiable Information (PII), 
even WHOIS-style information, about the end users behind identifiers. 
This could conceivably encompass the sorts of data that carriers and 
similar CSPs today keep about their customers for billing purposes, 
like real names and postal addresses. The exact nature of 
administrative data is not defined by this framework, and it is 
anticipated that the protocols that will perform this function will 
be extensible for different use cases, so at this point, it is 
difficult to characterize exactly how much PII might end up being 
housed by these services. 


As such, if an attacker were to compromise the registrar services 
that maintains administrative data in this architecture, and in some 
cases even service data, this could leak PII about end users. These 
interfaces, and the systems that host them, are a potentially 
attractive target for hackers and need to be hardened accordingly. 
Protocols that are selected to fulfill these functions must provide 
the security features described in Section 7. 


Finally, this framework recognizes that, in many jurisdictions, 
certain government agencies have a legal right to access service and 
administrative data maintained by CSPs. This access is typically 
aimed at identifying the users behind the communication identifier in 
order to enforce regulatory policy. Those legal entities already 
have the power to access the existing data held by CSPs in many 
jurisdictions, though, potentially, the administrative data 
associated with this framework could be richer information. 
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7. Security Considerations 


The acquisition, management, and retrieval of administrative and 
service data associated with telephone numbers raises a number of 
security issues. 


Any mechanism that allows an individual or organization to acquire 
telephone numbers will require a means of mutual authentication, of 
integrity protection, and of confidentiality. A Registry as defined 
in this document will surely want to authenticate the source of an 
acquisition request as a first step in the authorization process to 
determine whether or not the resource will be granted. Integrity of 
both the request and response is essential to ensuring that tampering 
does not allow attackers to block acquisitions, or worse, to 
commandeer resources. Confidentiality is essential to preventing 
eavesdroppers from learning about allocations, including the 
personally identifying information associated with the administrative 
or technical contracts for allocations. 


A management interface for telephone numbers has similar 
requirements. Without proper authentication and authorization 
mechanisms in place, an attack could use the management interface to 
disrupt service data or administrative data, which could deny service 
to users, enable new impersonation attacks, prevent billing systems 
from operating properly, and cause similar system failures. 


Finally, a retrieval interface has its own needs for mutual 
authentication, integrity protection, and confidentiality. Any CSP 
sending a request to retrieve service data associated with a number 
will want to know that it is reaching the proper authority, that the 
response from that authority has not been tampered with in transit, 
and, in most cases, the CSP will not want to reveal to eavesdroppers 
the number it is requesting or the response that it has received. 
Similarly, any service answering such a query will want to have a 
means of authenticating the source of the query and of protecting the 
integrity and confidentiality of its responses. 
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